Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux] - Mailing list pgsql-general

At 2:41 PM 7/24/98, Steve Doliov wrote:
>On Fri, 24 Jul 1998, Richard Lynch wrote:
>> At 8:28 AM 7/24/98, Marc Fournier wrote:
>> >        So, essentially, our VACUUM command provides functionality that
>> >Oracle *doesn't* have, right?
>> Yes, but yours doesn't run automatically.
>> <NAIVE>
>> Ideally, when one created a database, one could specify vacuum frequency
>> and/or time slot, and PostgreSQL would just do it...
>> </NAIVE>
>
>uh...isn't that what cron is for????

Sure.  If:

A.  The person who creates the database is allowed to add cron jobs.
    [A host ISP could easily and quite reasonably make this not be true.]
B.  You know that you need to run vacuum regularly.
C.  You know that cron runs regularly for tasks like this.
D.  The webmaster who creates the db knows enough Unix to add cron jobs.
    [See *long* section below:]

For most folks creating databases, all of the above is probably true.  But,
as PostgreSQL becomes more popular, and with the explosion of virtual
hosting, you're going to see a whole lot of users who will fail at least
one of the above.  Do you really want to keep answering this vacuum/cron
question every week?

Why should every PostgreSQL user have to set this up for every editable
database?  Isn't it an axiom to set things up for the most common
situtation, with over-rides for the uncommon, unless there are significant
performance penalties or other, similar, more important reasons not to do
so?

Actually...

<NAIVE MODE=SUPERNAIVE>
How hard would it be for PostgreSQL to count how many deletes there have
been (or measure fragmentation), and run vacuum after XXX deletes or when
needed?  What would be the performance penalty?  Then it could be totally
automatic, transparent to the user, and only hard-core folks who really
want to tune their performance would need to over-ride the automatic
check/vacuum somehow.
</NAIVE>

Disclaimer:
I'm a Macintosh Lisp hacker.  I'm lucky to remember the right flags to
untar something.  (-xvf?) Correction.  I have to go look them up to be
sure. I had to go look up my notes from a Unix friend just to do 'man 5
crontab' just now so I could get to the syntax of the date/time stuff in
the cron file.  More and more webmasters on virtual hosts are going to be
Unix-disabled and wanting to use PostgreSQL.


Super-long section telling you just why I have yet to set up cron to vacuum
my database every night.

Here's what I went through today trying to research this cron thing.  I
already know that cron automagically schedules tasks to happen on a regular
frequent basis, because somebody told me so.  That's all I know about it.

man cron.  Ah.  Okay.  I want crontab(1) or (5) to edit the cron files.

man crontab.  Okay.  What's the syntax for the crontab file?  Must be in (5).

Oh.  How do I get crontab (5)?

man man

Hmm.  Is that [section] thing the 5?  Would it always say "See also xxx(#),
but then the syntax to actually look it up is backwards?:  "man # xxx"
Yup.  God, that's stupid.  Why does Unix always have to be so damn
bassackwards?  They could at least have had an example.

man 5 crontab.  Wow.  Cool.  All sorts of permutations on time.

That MAILTO thing... What if it's defined outside, like, in the
"environment" I keep hearing about and never know how to set?
And those last two examples... they get mailed to Paul also, right?  No,
wait, just because I sent mail to Joe to annoy him doesn't mean Paul
doesn't get mail telling him Joe got mail just to annoy him... Right?  So
that first example must be the only one that doesn't send mail to Paul.
Otherwise, why would the second one say it sends mail to Paul.  Now I know
that 2>&1 stuff sends the errors somewhere...  Where?  Is this what
over-rides the mail to Paul?  Or is mail to Paul sent for all of these just
like it says in the comment before the MAILTO, and that note in the second
one is just totally superfluous?...  And what exactly does it mean "if it
has any reason to send mail as a result of running commands in ''this''
crontab"?  Oh, that's in cron(8).  Look that up later.

Well, let's try crontab -e and mess around to find out the answers to these
questions.  Or at least to see if I can just ignore this whole MAILTO thing
for now.  I can always do crontab -r and blow it away.

Damn! What's this PICO thing?  How do I make it use vi?

Thank god for PICO's instructions so I know how to quit!

man 5 crontab  I know it said something about the editor, but now I don't
see it...

man 5 crontab  Still don't see it...  Oh.  Duh.

man crontab   Ah.  Okay, how do I set the VISUAL or EDITOR variable[s]?
Which one do I set?  Both?  Is it, like, variant based on
BSD/Linux/ATT/whatever?

And if I do find out how to set it, how do I make it always stay set?

Oh hell.  Look at the time.  I give up.

Guess I'll just do vacuum by hand for now.  Sigh.

Maybe next week I'll have a free hour to waste looking up cron(8) and
whatever that leads me to, and trying to figure out this environment
variable crap so I can actually edit a crontab file using an editor I
learned 20 years ago, and still hate, but at least I know how it works.
And I guess I'll need to reread crontab(5) to figure out the time fields
again.  Joy.

--
--
-- "TANSTAAFL" Rich lynch@lscorp.com